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I. Basis of the report 

1, This report has been drawn on the basis of (substitute sheets which have been furnished to the receiving Office in 
response to an invitation under Article 14 are referred to in this report as "originally filed" and are not annexed to 
the report since they do not contain amendments (Rules 70. 16 and 70,17).): 
Description, pages: 

1-12 as originally filed 



Claims, No.: 

1 -21 as originally filed 



Drawings, sheets: 

1/14-14/14 as originally filed 



2. With regard to the language, all the elements marked above were available or furnished to this Authority in the 
language in which the international application was filed, unless otherwise indicated under this item. 

These elements were available or furnished to this Authority in the following language: , which is: 

□ the language of a translation furnished for the purposes of the international search (under Rule 23.1 (b)). 

□ the language of publication of the international application (under Rule 48.3(b)). 

□ the language of a translation furnished for the purposes of international preliminary examination (under Rule 
55.2 and/or 55.3). 

3. With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the 
international preliminary examination was earned out on the basis of the sequence listing: 

□ contained in the international application in written form. 

□ filed together with the international application in computer readable form. 

□ furnished subsequently to this Authority in written form. 

□ furnished subsequently to this Authority in computer readable iom. 

□ The statement that the subsequently furnished written sequence listing does not go beyond the disclosure in 
the international application as filed has been furnished. 

□ The statement that the information recorded in computer readable form is identical to the written sequence 
listing has been furnished. 

4. The amendments have resulted in the cancellation of: 

□ the description, pages: 

□ the claims, Nos.: 
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□ the drawings, sheets: 

5. □ This report has been established as if (some of) the amendments had not been made, since they have been 

considered to go beyond the disclosure as filed (Rule 70.2(c)): 

(Any replacement sheet containing such amendments must be referred to under item 1 and annexed to this 
report.) 

6. Additional observations, if necessary: 



V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations supporting such statement 

1. Statement 



Novelty (N) 


Yes: 


Claims 


1-9,11,12,14-21 




No: 


Claims 


10,13 


Inventive step (IS) 


Yes: 


Claims 






No: 


Claims 


1-21 


Industrial applicability (lA) 


Yes: 


Claims 


1-21 




No: 


Claims 





2. Citations and explanations 
see separate sheet 

VII. Certain defects in the international application 

The following defects in the form or contents of the international application have been noted: 
see separate sheet 

VIII. Certain observations on the international application 

The following observations on the clarity of the claims, description, and drawings or on the question whether the 
claims are fully supported by the description, are made: 
see separate sheet 
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With respect to section V: 

1 The following documents (D) are referred to in this communication; the numbering 
will be adhered to in the rest of the procedure: 

D1 : WO 96 421 73 A (BRITISH TELECOMMUNICATIONS PUBLIC LIMITED 

COMPANY) 27 December 1996 (1996-12-27) 
D2: US 4 800 488 (RAKESH AGRAWAL ET AL) 24 January 1 989 (1 989-01 -24) 

2 Document D1 which is regarded as representing the closest prior art to the 
subject-matter of claim 1 discloses a communications service platform 
comprising a number of general purpose computers which are coupled via a data 
communications network and may be widely distributed. According to Figure 3 of 
D1 (cp. page 3, line 16 to page 4, line 32), each of the computers comprises 
service resources which are registered by a location function when the resources 
are instantiated in one of the computer systrems. The location function routes 
arriving service requests aftenA/ards to the respective computer comprising the 
resource. 

Hence, document D1 discloses according to features of claim 1, a communica- 
tions service platform (Fig. 3: 22; page 1 , line 32 to page 2, line 2) comprising 

a multiplicity of loosely coupled subsystems, each of the subsystems 
including 

respective service processing resources (Fig. 3: 223; page 3, line 27 to 31); 

and 

a respective resource locator (Fig. 3: 40; page 4, lines 18 to 32), the re- 
source locator including means for receiving identity data and resource availability 
data (Fig. 3: 44; page 13, line 20 to 25). 

The communications service platform which is subject-matter of present claim 1 
differs from that known platform in that the respective resource locators include 
means for communicating to others of the resource locators data indicating the 
subsystems identity and data indicating the availability of resources in the respec- 
tive subsystems. 



Form PCT/Separate Sheet/409 (Sheet 1) (EPO-April 1997) 



INTERNATIONAL PRELIMINARY International application No. PCT/GB99/03347 
EXAMINATION REPORT - SEPARATE SHEET 



Location of resources is thus handled in a decentralized way whereby the com- 
puter systems are exchanging messages to register available service resources. 
Using this feature, no central resource location function will be needed. 

Document D2 which has not been cited in the international search report (a copy 
of the document is hereby appended) discloses a computer network, each 
computer comprising various resources and a server database indicating the 
availability of resources provided by other computer systems. The availability of 
resources is indicated by the computer comprising the resource by sending an 
advertisement message to other computers (col. 1 , lines 6 to 1 1 ; col. 2, line 18 to 
col. 3, line 57). 

Hence, it would be obvious to the person skilled in the art in order to provide a 
decentralized resource location mechanism, to apply these features with 
corresponding effect to a communications service platform according to document 
D1 , thereby arriving at a communications service platform according to claim 1. 

The subject-matter of claim 1 does therefore not involve an inventive step (Article 
33(3) PCT). 

3 Document D1 is regarded as representing the closest prior art to the subject- 
matter of independent claim 10. It discloses, according to the features of claim 10, 
a communications system (page 1 , lines 3 to 4) comprising: 

a plurality of call processing subsystems (page 1 , line 28 to page 2, line 13); 

a network interconnecting the plurality of call processing subsystems (page 
3, lines 20 to 21); 

a resource broker connected to the network, the resource broker including a 
data interface arranged to receive capability data and interface data from respec- 
tive call processing subsystems (page 4, lines 18 to 32), and 

Document D1 also implicitly discloses a registry arranged to store the said 
capability data and interface data because the location broker must comprise a 
database or the like to store the available resources and locations respectively 
(page 13, lines 20 to 25). 
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D1 thus discloses all the features of claim 10. The subject-matter of claim 10 is 
therefore not novel (Article 33(2) PCT). 

Even if the applicant would argue that the subject-matter of claim 10 is novel due 
to minor differences to the features disclosed in D1 , it could however not be 
considered as inventive because the differences would be too minor to justify an 
inventive step. 

4 Document D2 which is considered as representing the closest prior art to the 
subject-matter of claim 13 discloses, according to the features of claim 13, a 
computing platform comprising a multiplicity of loosely coupled subsystems 
(col. 1 , lines 6 to 1 1), each of the subsystems including respective data process- 
ing resources (col. 2, lines 44 to 51) and a respective resource locator arranged to 
advertise its identity and the loading of the respective resources and to receive 
resource signaling from others of the resource locators (col. 2, lines 33 to 36; 

col. 2, line 52 to col. 3, line 2). 

The subject-matter of claim 13 is therefore not novel (Article 33(2) PCT). 

5 Independent claim 14 relates to a method of operating a communications system. 
The method comprises the same combination of features as system claim 1 in 
form of method features. The same arguments as for claim 1 apply therefore also 
for claim 14, i.e. the subject-matter of claim 14 is rendered obvious by a combina- 
tion of the method of operating a communications system according to document 
D1 and the method of propagating resource information in a computer network 
disclosed by D2. 

6 Dependent claims 2 to 9, 11, 12 and 15 to 21 do not contain any features which, 
in combination with the features of any claim to which they refer, meet the require- 
ments of the PCT in respect of novelty or inventive step, because they are either 
known from documents D1 and D2 or represent, respectively, merely one of 
several straightforward possibilities from which the skilled person would select, in 
accordance with circumstances, without the exercise of inventive skill, in order to 
solve the respective problem posed. 



Form PCT/Separate SheeV409 (Sheet 3) (EPO-April 1997) 



INTERNATIONAL PRELIMINARY International application No. PCT/GB99/03347 
EXAMINATION REPORT - SEPARATE SHEET 



6.1 The subject-matter of dependent claim 2 is already disclosed in D2 (col. 2, line 18 
to col. 3, line 57). 

6.2 Dependent claims 3 to 5 and 19 relate to a resource broker mediating the 
communication between the resource locators. These features are already 
disclosed in D1 (page 4, lines 18 to 32; page 13, line 20 to 32). 

6.3 Dependent claims 6 to 9 relate to miscellaneous configurations of the communi- 
cations service platform where the location function is partly handled in a decen- 
tralized way by peer-to-peer signaling between the subsystems and partly medi- 
ated by the resource broker. The claims include merely combinations of the 
features of centralized or decentralized resource location disclosed either in D1 or 
D2, respect! veley, and are therefore lying within the design competence of a 
person skilled in the art. 

6.4 Dependent claims 11, 12, 20 and 21 relate to obvious implementation altema- 
tives for interconnecting the processing subsystems. 

6.5 Dependent claims 15 to 18 relate to obvious implementation alternatives for 
controlling and triggering the messages indicating the availability of resources. 

6.6 The subject-matters of dependent claims 2 to 9, 11, 12 and 15 to 21 do therefore 
not involve an inventive step (Article 33(3) PCT). 
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With respect to section Vli: 

1 Contrary to the requirements of Rule 5.1 (a)(ii) PCT, the relevant background art 
disclosed in the documents D1 and D2 Is not mentioned in the description, nor are 
these documents identified therein. 

2 Page 14, last line: the parenthesis is apparently superfluous. 



With respect to section Vlil: 

Claim 18 does not meet the requirements of Article 6 PCT in that the matter for 
which protection is sought is not clearly defined. It is not clear how a change in 
resource availability can exceed a threshold. 
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PROCESSING PLATFORM 



The present invention relates to a processing platform and particularly to 
telecommunications service platform using a number of loosely coupled 
5 subsystems. 

Platforms used, for example, to Implement advanced services in a 
telecommunications network having an IN (intelligent network) architecture, may 
comprise a number of loosely coupled subsystems linked by a high speed network. 
This structure enhances the capacity and the resilience of the platform. The 

10 resources of the platform are managed by a centralised management system that 
is responsible for allocating particular resources to given call and for reconfiguring 
the system, for example, in the event of one of the system components failing. As 
conventionally implemented, such a platform suffers the disadvantages of having a 
high management overhead and having poor scalability, that is, the platform is not 

1 5 readily adaptable to provide increased capacity. 

According to a first aspect of the present invention, there is provided a 
communications service platform comprising a multiplicity of loosely coupled 
subsystems, each of the subsystems including respective service processing 
resources and a respective resource locator, each resource locator including 

20 means for communicating to others of the resource locators its identity and the 
availability of the resources In the respective subsystem, and means for receiving 
identity data and resource availability data for resource locators in others of the 
subsystems. 

This aspect of the invention provides a service platform which maintains 
25 the resilience and capacity of a distributed processing architecture while reducing 
the management overheads and providing greatly improved scalability. This Is 
achieved by providing each subsystem with a resource locator which advertises 
the resources of the relevant subsystem and also listens to information from other 
subsystem. In this way the task of resource management and allocation is 
30 distributed between the subsystems, and the system as a whole is provided with a 
mechanism for recognising and responding to the addition of new subsystems. 

The resource locators may be arranged to communicate directly by peer- 
to-peer signalling. Preferably, however, the platform Includes a resource broker 
and communication between the resource locators is mediated by the resource 
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broker. The resource broker may be located in one of the service processing 
subsystems, or may be located in a dedicated platform. The resource broker may 
include a data interface arranged to receive capability data and interface data from 
respective resource locators, and a registry arranged to store the said capability 
5 data and interface data. Preferably a resource locator in a subsystem is arranged 
initially to read capability data and interface data for another subsystem from the 
resource broker, and subsequently communicates further data directly with the 
other subsystem using the interface of the subsystem identified in the said 
interface data. 

10 The system developed by the present inventors is not limited to use in 

communications systems but may also be used in a general computing 
environment. 

According to a second aspect of the present invention there is provided a 
computing platform comprising a multiplicity of loosely coupled computing 

15 subsystems, each of the said subsystems including respective data processing 
resources and a respective resource locator arranged to advertise its identity and 
the loading of the respective resources and to receive resource signalling from 
others of the resource locators . 

According to a third aspect of the present invention, there is provided a 

20 method of operating a communications system, the system including a 
multiplicity of processing subsystems and a network interconnecting the 
multiplicity of subsystems, the method comprising; 

a) communicating from a resource locator in a respective one of the 
multiplicity of subsystems to resource locators in others of the multiplicity of 

25 subsystems data indicating the identity of the said one subsystem and the 
availability of resources in the said one subsystem 

b) repeating step (a) for each other of the multiplicity of subsystems: 

c) when one of the multiplicity of subsystems, in the course of processing 
a call, requires resources not present locally in the said subsystem: 

30 i) identifying from the said data communicated to the resource 

locator of the said one subsystem another subsystem having the said resources; 
ii) accessing the said subsystem via the network. 
According to a fourth aspect of the present invention, there is provided a 
communications system comprising: 
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a plurality of call processing subsystems; 

a network interconnecting the plurality of call processing subsystems; 
a resource broker connected to the network, the resource broker including 
a data interface arranged to receive capability 
5 data and interface data from respective call processing subsystems, and 

a registry arranged to store the said capability data and interface 

data. 

The term "call processing subsystem" is used here broadly to encompass 
systems ancillary to the processing of a call, such as, e.g., an Email server, a 
10 mobility application platform or an interactive voice response (IVR) platform, as 
well as systems, such as a communications server, which are directly involved in 
the handling of a call. 



15 Systems embodying the present invention will now be described in further 

detail, by way of example only, with reference to the accompanying drawings in 
which; 

Figure 1 is a schematic of network embodying the invention; 
Figure 2 is a diagram showing the structure of a service control point in 
20 Figure 1; 

Figure 3 is a schematic of a network employing peer-to-peer signalling: 
Figure 4 is a schematic of a network employing a broker; 
Figure 5 is a diagram showing interactions between a broker and 
components; 

25 Figure 6 is a schematic showing an architecture implementing the 

invention; 

Figure 7 is a class diagram for an implementation of the architecture of 
Figure 6; 

Figure 8 is a message flow diagram showing a first scenario; 
30 Figure 9 is a message flow diagram showing a second scenario; 

Figure 10 is a schematic of an implementation of the architecture of Figure 
6 across different networks; 

Figure 1 1 is a diagram illustrating different interface types in a system 
embodying the invention; 
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Figure 1 2 is a diagram showing the structure of a resource broker; 
Figure 13 shows a system in which components incorporate both type 1.0 
and type 2.0 interfaces 

Figure 14 shows a personal mobility service implemented using the 
5 architecture of Figure 6. 

A telecommunications network which uses an IN (Intelligent Network) 
architecture includes a service control point 1, which is also termed herein the 
Network Intelligence Platform (NIP). The service control point 1 is connected to 

10 trunk digital main switching units (DMSU's) 2 ,3 and to digital local exchanges 
(DLE's) 4,5. Both the DMSU's and the DLE's function as service switching points 
(SSP's). At certain points during the progress of a call, the SSP's transfer control 
of the call to the service control point. The service control point 1 carries out 
functions such as number translation and provides a gateway to additional 

15 resources such as a voice messaging platform. The network also includes a 
second service control point 6, which in this example runs customer mobility 
applications. The two service control points are connected to each other and to 
the other components via a broadband signalling network 7. 

Figure 2 shows the structure of the service control point 1 . A service 

20 management server is connected via an FDDI optical fibre LAN 21 to an overload 
control server (OCS) and to transaction servers (TS). The overload control server 
monitors call rates and initiates action to protect the SCP and other elements of 
the network from overload. For example the OCS may send a call-gapping 
instruction to an originating exchange. Additionally or alternatively, a call-gapping 

25 instruction may be sent to the broker, so that the broker rations the availability, 
e.g., of switching resources at the originating exchange so as to protect other 
resources downstream of the originating exchange. The transaction servers 
implement advanced service control functions such as, for example number 
translation and call plans. The OCS and transaction servers are connected via a 

30 second FDDI LAN 22 to communications servers (CS) which are connected to an 
SS7 (ITU Signalling System no. 7) signalling network. A global data server (GDS) 
is also connected to this second LAN. The GDS records call statistics and may 
also be used in the operation of overload control functions. 
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Figure 3 is a simplified schematic of the network of Figure 1, illustrating a 
first implementation of the present invention. The Figure shows a first SCP 31, a 
second SCP 32 and a DMSU 33. These components constitute loosely coupled 
subsystems of a platform which runs one or more IN services. The subsystems are 
5 connected by a broadband signalling network 34, for example an FDD! LAN. As 
indicated by the key to the Figure, each subsystem includes call processing 
resources of different types and also a resource locator 35. The first SCP 
includes resource types 1 and 2 which might correspond, for example, to a VPN 
(virtual private network) control function and to a number translation function 

10 respectively. The second SCP includes type 1 resources, and the DMSU includes 
resource type 3, for example a call switching function. Each locator advertises to 
all other locators, the identity and location of the subsystem, the resources 
available at that location and, for example, the loading of the resources. For 
example the locator in the first SCP 31, when the SCP is initiated, broadcasts to 

15 the other resource locators, a message in the form (SCP1; addressi; type 1, 50%; 
type 2, 90%) where the first field is the identity, the second field is the address, 
and the subsequent fields are resource types and include a measure of resource 
loading. This message is received and stored by the resource locators in the other 
subsystems, and they in turn broadcast resource messages which are received by 

20 the resource locator in the SCP 31. The step of broadcasting resource messages 
is repeated periodically, with a frequency chosen to balance the need of the 
system to re-balance resources after a subsystem failure, or after incremental 
changes in the proportion of free resources in a subsystem, against the need to 
minimise signalling overheads. In the present example, resource locators re- 

25 transmit a resource message every 10 seconds. Then, for example, if a call 
originating at the DMSU is making use of VPN resources in the first SCP, and the 
first SCP fails, the failure will become apparent within, at most 10 seconds, and 
the DMSU resource locator may identify alternative resources in the second SCP. 
The absence of an expected update is interpreted by the resource locators as an 

30 indication that the corresponding resources have become unavailable. In addition, 
subsystems may update the resource locators in response to events within that 
subsystem. For example, a subsystem may be programmed to update the resource 
locators whenever its loading changes by more than a predetermined threshold, 
e.g. 20%. 
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Figure 4 is a schematic illustrating a second implennentation of the 
invention. In this example, in addition to the first and second SCP's and the 
DMSU described above with reference to Figure 3, the system also includes a 
resource broker 40. The resource broker includes, in addition to its own resource 
5 locator 41, a data store 42 which holds a registry of data communicated by other 
subsystems, and an authentication processor 43 which authenticates data 
received from the subsystems prior to entering the data in the registry. The broker 
may be implemented on a commercially available system such as that available 
from Visigenics as the Visigenics ORB (object request broker) running, for example, 

10 on a Digital SPARC Ultra (trademark) workstation. As shown in Figure 5, a 
subsystem, here termed a "component", must first authenticate itself with the 
broker, for example using a password or a digital signature, and agree a security 
mechanism for further exchanges. The component then registers its interfaces with 
the broker. For example, a communications server might register an INAP 

15 communications channel at a specified network address. From this point, the 
component can discover the interfaces of other components within the system by 
reference to the registry in the broker. Once the component understands the 
interfaces of other components it can communicate freely with the other 
components without further reference to the broker. 

20 Figure 1 2 shows in further detail the structure of the resource broker 40. 

It comprises a resource registry, a service registry, and modules for authentication, 
registration and discovery. Tables 1 and 2 below show examples of the contents 
of the resource registry and service registry respectively. Each resource in the 
resource registry may have linked with it a number of entries in the service 

25 registry. 
TABLE 1 
Name: Athena 

Processor: Digital SPARC Ultra 
Address: 132.14.32.71 
Function: Call Control Server 



TABLE 2 

Call ControhlNAP 
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no. RANGE 64XXXX-67XXXX 
Network Operator: BT 
Capacity: 1 0Q cps 
Security parameters: 

authentication level 

signature 
Interface: VIPER 1.0 



Figure 6 shows an overview of an architecture that is implemented using a 
resource broker as described above with reference to Figures 4 and 5. The broker 
and the network used by the subsystems to communicate with the broker together 
5 provide a brokered environment 60. In this example, the subsystems connected to 
the brokered environment 60 include a PSTN network 61, a gatekeeper 62 for 
voice over IP (internet protocol) services, fax resources 63, an Email server 64 and 
a voice mail server 65 . A number of applications use the resources of the 
subsystems 61-65. These applications locate the appropriate resources using the 

10 resource broker contained within the brokered environment 60. This 
implementation is termed by the inventors the "VIPER" architecture. The 
architecture provides for two types of interfaces, termed by the inventors VIPER 
1.0 and VIPER 2.0. As illustrated in Figure 11, VIPER 2.0 interfaces provide for 
communication between subsystems via an object bus 110. Subsystems using 

1 5 VIPER 2 interfaces request resources from a resource broker on a per call basis and 
communicate using, e.g., the CORBA protocol. VIPER 1 interfaces bypass the 
object bus and use specific protocols such as INAP to communicate with other 
systems. Subsystems with VIPER 1 interfaces register and discover resources and 
interface details with the resource broker when the subsystem is initialised, but do 

20 not communicate with the resource broker for subsequent calls. Such subsystems 
using VIPER 1 interfaces then communicate with other subsystem using protocols 
specific to the subsystem, for example INAP in the case of a communications 
server communicating with a transaction server. 

In operation, a subsystem such as a communications server may initially 

25 download copies of service and resource registry data from the resource broker to 
form a locally cached copy of the resource broker. For example, in Figure 1 1, the 
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communications server CS may optionaily include a locally cached broker (LCB), as 
shown in dashed lines in the Figure. Then discovery operations may be carried out 
using the locally cached copy of the resource broker. In this case, even where a 
VIPER 2.0 interface is used, it is not necessary for signalling to pass between the 
5 communications server and the remote broker on every call. Instead, data passes 
between the remote broker and the communications server only intermittently 
when it is necessary to refresh the locally cached resource broker. Although the 
communications server, if it employs a VIPER 2.0 interface, still interrogates the 
resource broker for each new call, it is in general the locally cached broker that is 

10 used for this purpose. 

Figure 7 is a class diagram showing an implementation of the architecture 
of Figure 6. This diagram is generated using the Rational ROSE software 
engineering tool and provides a basis, using that tool, for generating, e.g., Java 
code implementing the invention. Rational ROSE is available commercially from 

15 Rational Software Corporation. In this implementation, the subsystems that 
interact using the broker are termed "plugins". 

Figure 8 shows a network operator bringing a VIPER broker, a VIPER 
Cambridge Transaction Server and a ViPER Cambridge Communications Server into 
service. "Cambridge" is the name given to the SCP illustrated in Figure 2. After 

20 registration and discovery is complete, an incoming call triggers an INAP 
(Intelligent Network Application Protocol) IDP (initial detection point) at a DLE. 
The DLE is referenced GPT_SSP in the diagram. The call is cut-through the VIPER 
middleware. Since the communications server CS and transaction server TS have 
both registered ViPER 1.0 interfaces with the resource broker, the CS does not 

25 have to ask the broker each time a call is received for the address of a suitable 
service resource or "plugin". Instead the CS and TS communicate directly using an 
INAP interface and bypassing the object bus. After location lookup is performed, 
an INAP connect is also cut-through the VIPER middleware back to the SSP. The 
following events and messages are shown in Figure 8: 

30 

1 ; Network operator brings the VIPER broker into service. 
2: VIPER broker registers it services with itself if necessary. 
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3: Network operator brings the VIPER Cambridge Transaction Server into service. 

4: VIPER Cannbrldge Transaction Server registers itself as a PlugIN with the VIPER 
broker. 

5 

5: VIPER Cambridge Transaction Server registers the services it supports with the 
VIPER broker. 

6: Network operator brings the VIPER Cambridge Communications Server into 
1 0 service. 

7: VIPER Cambridge Communications Server registers itself as a PlugIN with the 
VIPER broker. 

15 8: VIPER Cambridge Communications Server registers the services it supports with 
the VIPER broker. 

9. VIPER Cambridge Transaction Server requests the address of the PlugIN 
associated with 'name' (in this case, VIPER Cambridge Communications Server). 

20 

10. VIPER Cambridge Communications Server requests the address of the PlugIN 
associated with 'name' (in this case, VIPER Cambridge Transaction Server). 

11. GPT SSP sends an INAP Initial Detection Point (IDP) to the VIPER Cambridge 
25 Communications Server. 

12. VIPER Cambridge Communications Server sends a INAP IDP to the VIPER 
Cambridge Transaction Server. 

30 13. VIPER Cambridge Transaction Server does an internal location lookup, then 
sends an INAP connect to the VIPER Cambridge Communications Server. 

14. VIPER Cambridge Communications Server sends an INAP connect to the GPT 
SSP. 
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Figure 9 shows the message flows involved in a second scenario, with a 
network operator bringing a VIPER broker, a VIPER Mobility Server and a VIPER 
Cambridge Communications Server into service. The VIPER mobility server may be, 
5 for example, the SCP 6 running a mobility application illustrated in Figure 1 . Once 
registration is complete, an incoming call triggers an INAP IDP into the VIPER 
middleware. A communications server CS creates a call model {labelled "INAP call" 
in Figure 9) and passes control of the service to that call model. The call model 
communicates with the resource broker to identify an application that is capable 

10 and ready to provide the resources required by the service. That application, if not 
already running, is created. The call model then request the application, in relation 
to this call, to perform a location look-up for the called party. On completion of 
the look-up, a mobile address returned by the look-up is passed to the 
communications server and the VIPER middleware send an INAP connect to the 

1 5 SSP. 

1: Network operator brings the VIPER broker into service. 
2: VIPER broker registers it services with itself if necessary. 

20 

3: Network operator brings the VIPER Mobility Server into service. 

4: VIPER Mobility Server registers itself as a PlugIN with the VIPER broker. 

25 5: VIPER Mobility Server registers the services it supports with the VIPER broker. 

6: Network operator brings the VIPER Cambridge Communications Server into 
service. 

30 7: VIPER Cambridge Communications Server registers itself as a PlugIN with the 
VIPER broker. 

8: VIPER Cambridge Communications Server registers the services it supports with 
the VIPER broker. 
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9. GPT SSP sends an INAP Initial Detection Point (IDP) to the VIPER Cambridge 
Connmunications Server. 

5 10 & 11. The VIPER Cambridge Communications Server creates a new call model 
to handle this service and then initiates the Call Model's constructor. 

12. The Call Model requests from the VIPER broker the address of the PlugIN (in 
this case, the VIPER Mobility Server) capable of providing the service described 

10 within the service descriptor. 

13, 14 & 15. The Call Model requests from the VIPER Mobility Server the address 
of the application capable of servicing the request. This causes the VIPER Mobility 
Server to create a Roaming Application and then initiate the Roaming Application's 

15 constructor. Flow 14 is optional depending on whether the Roaming Application is 
active or not. 

16. The Call Model sends a VIPER 2.0 equivalent of an INAP IDP to the Roaming 
Application. 

20 

17. The Roaming Application performs a location lookup. 

18. The Roaming Application sends a VIPER 2.0 Connect to the Call Model. 

25 19. The Call Model sends an internal PlugIN connect to the VIPER Cambridge 
Communications Server. 

20. The VIPER Cambridge Communications Server send an INAP connect to the 
GPT SSP. 

30 

Figure 10 illustrates an implementation of the VIPER architecture which 
provides a service platform which is distributed over different networks that may 
be located in different continents. In this example a customer at a customer 
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terminal 100 is registered with a mobility application resident on a first application 
server connected to a first broadband signalling network e.g. in the UK. The 
customer terminal is connected via a digital local exchange DLE to a second 
broadband signalling network, e.g., in the US. The first and second national 
5 networks are interconnected via a jointly operated international network 103. 
Resource brokers (referenced B) are connected to the networks and the resources 
available on each network are registered with the resource brokers. The resource 
brokers communicate data to each other via a global broker GB, so that, for 
example, the broker B connected to network 102 has in its registry details of 

10 resources on both network 101 and network 102. The communication between 
brokers may be implemented, e.g., using CORBA or HOP over IP. 

In operation, the customer at terminal 100 registers their current location 
with the mobility application on the first application server. To do this, they dial 
the number associated with the service. This triggers an IDP at the SSP. The SSP 

1 5 requests from a local broker B the address of the application required to service the 
call. The local broker B communicates with the global broker GB connected to 
network 103 to obtain interface and address data to allow the SCP to 
communicate with application server 1 . The mobility application may, for example, 
require the use of an interactive voice response (IVR) system to accept data from 

20 the customer. This resource is provided within network 101 by a first intelligent 
peripheral IP1. However, the second network includes its own IVR resources 
provided by a second intelligent peripheral IP2. The mobility application requests 
discovery of IVR resources from the broker B. After communication with the 
global broker GB, the broker returns detail of the IP2 that is local to the customer 

25 at the current customer location. The application server 1 uses this information to 
return an INAP connect message to the SSP to set up a connection between the 
customer terminal and IP2. 
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CLAIMS 

1 . A communications service platform comprising: 

a multiplicity of loosely coupled subsystems, each of the subsystems 
including 

5 respective service processing resources; and 

a respective resource locator, each resource locator including means 
for communicating to others of the resource locators data indicating 
the subsystem identity and data indicating the availability of 
resources in the respective subsystem, and means for receiving 
10 identity data and resource availability data for resource locators in 

others of the subsystems. 



2. A platform according to claim 1, in which the resource locators are arranged to 
communicate directly with each other by peer-to-peer signalling. 

15 

3. A platform according to claim 1 or 2, further comprising a resource broker and 
in which at least some communication between the resource locators is mediated 
by the resource broker. 

20 4. A platform according to claim 3, in which the resource broker is located in one 
of the said subsystems. 



5. A platform according to claim 3 or 4, in which the resource broker includes: 

a data interface arranged to receive capability 
25 data and interface data from respective resource locators, and 

a registry arranged to store the said capability data and interface data 

6. A platform according to any one of claims 3 to 5, in which a resource locator in 
a subsystem is arranged initially to read capability data and interface data for 

30 another subsystem from the resource broker, and subsequently communicates 
further data directly with the other subsystem using the interface of the subsystem 
identified in the said interface data. 
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7. A platform according to any one of claims 3 to 6, in which at least one of the 
subsystems is arranged to communicate directly with a selected other subsystem 
via a respective specific data interface and in which others of the subsystems are 
arranged to communicate with a selected other subsystem via an object bus. 

5 

8. A platform according to claim 7 in which the or each said subsystem arranged 
to communicate directly via a respective specific data interface is arranged, on 
initialisation of the said subsystem, to read data for the selected other subsystem 
from the resource broker, and in response to calls subsequent to the initialisation 

10 of the subsystem, communicates directly with the selected other subsystem 
without reference to the resource broker. 

9. A platform according to claim 7 or 8, in which the said subsystems arranged to 
communicate via an object bus are arranged, in response to each new call, to read 

1 5 resource data from the resource broker. 

10. A communications system comprising: 

a plurality of call processing subsystems; 

a network interconnecting the plurality of call processing subsystems; 
20 a resource broker connected to the network, the resource broker including 

a data interface arranged to receive capability 
data and interface data from respective call processing subsystems, and 

a registry arranged to store the said capability data and interface 

data. 

25 

11. A communications system according to claim 10, further comprising an object 
bus interconnecting at least some of the call processing subsystems. 

12. A communications system according to claim 1 1 , in which communication 
30 paths between others of the subsystems bypass the object bus. 

13. A computing platform comprising a multiplicity of loosely coupled computing 
subsystems, each of the said subsystems including respective data processing 
resources and a respective resource locator arranged (to advertise its identity and 
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the loading of the respective resources and to receive resource signalling from 
others of the resource locators . 

14. A method of operating a communications system, the system including a 
5 multiplicity of processing subsystems and a network interconnecting the 

multiplicity of subsystems, the method comprising; 

a) communicating from a resource locator in a respective one of the 
multiplicity of subsystems to resource locators in others of the multiplicity of 
subsystems data indicating the identity of the said one subsystem and the 

10 availability of resources in the said one subsystem 

b) repeating step (a) for each other of the multiplicity of subsystems: 

c) when one of the multiplicity of subsystems, in the course of processing 
a call, requires resources not present locally in the said subsystem: 

i) identifying from the said data communicated to the resource 
1 5 locator of the said one subsystem another subsystem having the said resources; 

ii) accessing the said subsystem via the network. 

15. A method according to claim 14, in which, for each of the multiplicity of 
subsystems, step (a) is repeated regularly. 

20 

16. A method according to claim 15, in which the period of repetition for step (a) 
is small compared to the mean duration of a call processed by the communications 
system. 

25 17, A method according to any one of claims 14 to 16, in which, for at least one 
of the multiplicity of subsystems, step (a) is repeated in response to an event in 
the respective subsystem, 

18. A method according to claim 17, in which the said event is a change in 
30 resource availability in the subsystem exceeding a predetermined threshold. 

19. A method according to any one of the preceding claims in which the 
communication of resource data between subsystems is mediated by a resource 
broker. 
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20. A method according to claim 1 9, in which data is communicated between at 
least some of the subsystems and the resource broker via an object bus. 

5 21. A method according to claim 20 in which data is communicated between 
others of the subsystems directly, bypassing the object bus. 




SUBSTITUTE SHEET (RULE 26) 



wo 00/22842 




PCT/GB99/03347 



2/16 




SUBSTITUTE SHEET (RULE 26) 



wo 00/22842 



PCT/GB99/03347 



3/16 







Fig.3. 
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